Remarks 

In the final Office Action mailed December 3, 2003: 

1. Claims 1-3, 5-7, 9-22 and 24-32 were rejected under 35 U.S.C. § 103(a) in view 
of U.S. Patent No. 5,844,890 (Delp); and 

2. Claim 8 was rejected under 35 U.S.C. § 103(a) in view of Delp and U.S. Patent 
No. 5,732,094 (Petersen). 

I. Delp (U.S. Patent No. 5,844,890) 

Delp is intended to describe "a method for scheduling cell transmissions that provides 
proportional use of available network bandwidth" (column 1, lines 22-24). Because Delp is 
concerned with proportional use of network bandwidth, and does not allow dynamic adjustment 
of the amount of data a channel can transmit, it cannot make obvious the claimed embodiments 
of Applicant's invention. 

A, Delp Does Not Use Dynamic Weights Associated with Memories for 
Controlling How Much Data is Sent 

In Delp, data cells of a data stream are stored in queues, for which target transmission 

times are calculated using parameters associated with the stream's logical channel (column 3, 

lines 3 1-34). Queues are assigned to appropriate time slots in the timing wheels, to attempt to 

meet the target transmission times (column 3, lines 34-37). Each slot apparently allows a single 

transmission from whichever data cell queue is assigned to the slot and is active when the slot 

becomes the current slot. All slots are apparently equal in the amount of data cells they allow to 

be scheduled. 

A claimed embodiment of Applicant's invention (e.g., claim 1) employs a plurality of 
memories having dynamic weights corresponding to threshold amounts of data permitted to be 
scheduled during each memory's turn. 

The Examiner states that "by placing a limit on the amount of time for a timing wheel, 
Delp provides means for maintaining a dynamic weight" for the data cell queues, "wherein the 
weight corresponds to a threshold amount of data according to the time and the established bit 
rate" (first full paragraph on page 3 of final office action). 

However, each slot apparently allows the same amount of data to be transmitted, and 
does not change - thus, Delp does not employ dynamic weights, if it uses any weights at all. 
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Further, Delp does not associate any threshold timing, weight or limit with the Logical Channel 
Descriptors (LCDs) or the queues in which data packets are stored. The LCDs simply hold data 
until the timing wheels reach slots for which an LCD has been scheduled. 

If it is the Examiner's contention that Delp's timing wheels have the specified threshold 
times associated with them, this conflicts with other claim rejections. In particular, the Examiner 
states in paragraph 4 of the final office action that the "plurality of memories" recited in claim 1 
corresponds to Delp's "queue of data descriptors" or LCDs. But claim 1 of the application 
specifies that it is the plurality of memories that have dynamic weights corresponding to 
threshold amounts of data. 

B. Delp Does Not Compare an Amount of Data Sent to a Threshold 

Delp schedules data for transmission based on slots in a timing wheel (column 5, lines 
62-66). The Examiner has stated that Delp teaches placing a limit or weight corresponding to a 
threshold time that corresponds to a threshold amount of data, wherein the threshold time 
corresponds to time slots in a timing wheel (first full paragraph of page 3 of the final office 
action). 

It is therefore understood by Applicants that the Examiner is asserting that Delp 
associates a threshold amount of data for a queue, wherein the threshold data amount is equal to 
the time period represented by the time slot(s) assigned to the queue, multiplied by the bit rate. 

It is therefore im possible for Delp to exceed that threshold amount of data. During each 
turn or slot, the cell scheduler 102 in Delp can only schedule an amount of data corresponding to 
the slot assigned to a given queue (i.e., the "threshold amount"), no more. 

Thus, there is no comparison of data amounts in Delp. The scheduler looks in the current 
frame of a timing wheel, finds the active, assigned queue(s), and schedules data from the 
queue(s). The scheduler cannot and does not adjust the size of a slot or continue servicing a 
queue after its current slot has ended and the next slot has begun. Each queue's turn, or each 
slot, results in a set amount of data being transmitted, no more. 

One or more claimed embodiments of Applicant' s invention (e.g., claim 1) have been 
amended to demonstrate more clearly that more than the threshold amount of data may be 
scheduled during a memory's turn. 

The Examiner cited to FIG. 7 and column 8, lines 45-67 of Delp as teaching this aspect of 



SUN-P3992 



12 



Applicants' invention. "FIG. 7 is a flow chart illustrating sequential operations of the cell 
scheduler of the preferred embodiment of FIG. 1 to determine a move to a next time slot" 
(column 4, lines 30-32; emphasis added). Thus, FIG. 7 and the accompanying text deal with 
selecting a next time slot, not determining whether an amount of data scheduled for transmission 
exceeds a threshold amount. The accompanying text says nothing about an amount of data that 
has been transmitted or scheduled for transmission : 
700: start; 

702: search the current frame for an active bit that is on; 

704: if no active bits that are on are found, a next frame is read; 

706: if an active bit that is on is found, move to the corresponding slot; 

708: done; 

710: check whether a slow wheel boundary is crossed; 
712: if a slow wheel boundary was crossed, start slow wheel processing as 
shown in FIG. 7A. 

Applicants can find no mention of anything similar to the "determining" action recited in claim 1 
of the application. 

C. Delp does not Decrease a Threshold Amount of Data when an Amount of 
Data Scheduled for Transmission Exceeds the Threshold 

Delp schedules data for transmission based on slots in a timing wheel (column 5, lines 

62-66). The Examiner has stated that Delp teaches placing a limit or weight corresponding to a 

threshold time that corresponds to a threshold amount of data, wherein the threshold time 

corresponds to time slots in a timing wheel (first full paragraph of page 3 of the final office 

action). 

However, the timing wheel slots of Delp apparently allow only a fixed amount of data to 
be scheduled. The cumulative amount of data being sent for a given queue is apparently 
controlled by the frequency with which the queue is assigned to a slot (e.g., FIGs. 10-13; column 
11, lines 1-27). For example, the invention is described in the context of an ATM cell scheduler 
(column 5, lines 7-12), which requires fixed size cells (column 1, lines 54-55). 

Because Delp uses fixed size time slots, Delp cannot decrease a threshold amount of data 
to be scheduled for transmission from a queue during a subsequent servicing turn. Each time the 
queue is scheduled, it is for a set amount of data. This is logical, as Delp is designed to provide 
"proportional use of available network bandwidth" (column 5, lines 14-15) for multimedia 
applications (column 1, lines 28-33), which are characterized by steady streams of data. 
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In the final office action, the Examiner stated that "by teaching adjusting the allotted time 
for transmission, Delp teaches adjusting the amount of data scheduled by determining an 
adjusted allotted time having an established bit rate," Applicants disagree and are unsure how 
Delp is being interpreted to "teach[ ] adjusting the allotted time." 

Delp services a given queue during its assigned slot, and then schedules a next slot based 
on appropriate parameters (e.g., column 6, lines 43-53). Delp apparently cannot and does not 
adjust the size of slots in a timing wheel or the amount of data scheduled for transmission during 
a slot. There is no mention of decreasing the size of a slot. 

Even if Delp could be interpreted as altering the frequency with which a queue is 
scheduled, Delp doesn't do so after determining whether an amount of data scheduled for 
transmission was greater than a threshold associated with the queue from which the data was 
scheduled. 

D. Delp does not Monitor an Amount of Data Retrieved During Servicing 

Delp does not appear to include an entity comparable to the arbiter of claim 25, which 
may be responsible for making the determination described in section LB. 

For this element, the Examiner cited block 720 of FIG. 7A, which is described at column 
9, lines 12-18. "FIG. 7A is a flow chart illustrating exemplary steps for processing the slow 
timing wheel data of FIG. T (column 4, lines 33-34; emphasis added). Decision block 720 asks 
whether any entries remain in the current segment of the slow timing wheel. This is a Boolean 
test, and is answered yes or no. There is no need for, or mention of, monitoring the amount of 
data retrieved from a memory. In particular, the answer to block 720 would be the same 
regardless of whether the current segment was full of entries or contained but one entry. 

And, the number of entries in the segment is merely a precursor to moving the associated 
LCD to a new location on either the fast or slow timing wheel. This does not involve the 
retrieval of any data from the LCD. 

II. Selected Claims 

A. Claims 1-3, 5-10, 32 

As described above, Delp does not teach or suggest the following elements of claims 1 

and 32: 
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maintaining a dynamic weight for each of said plurality of 
memories, wherein each said dynamic weight corresponds to a threshold 
amount of data associated with said predetermined priority; 

retrieving data described by said received descriptor, 
wherein the amount of retrieved data may exceed said threshold 
amount; 

determining whether an amount of data scheduled during 
said servicing for transmission via said communication link 
exceeds said threshold amount of data corresponding to said 
dynamic weight for said serviced memory; 

... and 

if said amount of data scheduled for transmission exceeds 
said threshold amount of data, decreasing said threshold for a next 
servicing of said serviced memory. 

Regarding the use of dynamic weights, in the final office action the Examiner stated that 

it is the Examiner's contention that by placing a limit on the 
amount of time for a timing wheel, Delp provides means for maintaining a 
dynamic weight for the memories wherein the weight corresponds to a 
threshold amount of data according to the time and the established bit rate. 

Applicant is unsure what "placing a limit on the amount of time for a timing wheel" means. The 
timing wheels of Delp apparently cycle continuously, and the "time" measured by a timing 
wheel is measured in slots, not convention time unit (i.e., seconds, minutes). If it is the length of 
time associated with one time slot that is meant by this phrase, then it is incorrect, because Delp 
does not alter the size of slots in a timing wheel. Even if it is the number of slots to which a 
queue is assigned, Applicants still disagree with the contention. Delp only schedules one slot at 
a time. Each time a queue is serviced during a slot, its next slot is assigned (e.g., column 6, lines 
26-41; column 6, lines 47-53). 

B. Claims 11-22,24 

The rejections of claims 1 1 and 24 are traversed for the reasons stated in sections I and 
II.A above. 

In addition, claims 1 1 and 24 recite the following: 

in a first servicing turn of said first memory: 
determining whether one of said first weight and said second 
weight has changed; 
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When Delp is scheduling data from one LCD during a slot, it does not consider any other 
LCDs. Therefore, even if Delp could be interpreted as teaching the use of dynamic weights 
corresponding to threshold amounts of data, Delp does not look at one LCD's parameters when 
servicing another. 

C Claims 25-31 

The rejections of claims 25-31 are traversed for the reasons stated above in sections I and 

II.A. 

CONCLUSION 

No new matter has been added with the preceding amendments. It is submitted that the 
application is in condition for allowance. Such action is respectfully requested. If prosecution of 
this application may be facilitated through a telephone interview, the Examiner is invited to 
contact Applicant's attorney identified below. 



Respectfully submitted, 



Date: January 5. 2004 




42.199 

(Registration No.) 



Park, Vaughan & Fleming LLP 

702 Marshall Street, Suite 310 
Redwood City, CA 94063 
(650) 474-1973: voice 
(650) 474-1976: facsimile 
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